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DETAILED A CTION 

1 . Claims 1-12 are pending. 

2. Claims 1-12 are rejected. 

3 . Pre-amendment has been considered. 

Information Disclosure Statement 

4. The Information Disclosure Statement (IDS) submitted on 12/12/2003 and 04/13/2004 
are in compliance with the provisions of 37 CFR 1 .97. Accordingly, the IDS statement is being 
considered by the examiner. 

Priority 

5. Acknowledgment is made of applicant's claim for foreign priority under 35 
U.S.C. 1 19(a)-(d). The certified copy has been filed in parent Application No. 02293184 (EPO), 
filed on 12/20/2002. 

Drawings 

6. The drawings filed on 12/12/2003 are accepted by the examiner. 

Specification 

7. Applicant is reminded of the proper language and format for an abstract of the disclosure. 
The abstract should be in narrative form and generally limited to a single paragraph on a separate 
sheet within the range of 50 to 150 words. It is important that the abstract not exceed 150 words 
in length since the space provided for the abstract on the computer tape used by the printer is 
limited. The form and legal phraseology often used in patent claims, such as "means" and "said," 
should be avoided. The abstract should describe the disclosure sufficiently to assist readers in 
deciding whether there is a need for consulting the full patent text for details. 

The language should be clear and concise and should not repeat information given in the 
title. It should avoid using phrases which can be implied, such as, "The disclosure concerns," 
"The disclosure defined by this invention," "The disclosure describes," etc, but not the copy of a 
claim. 
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Claim Rejections - 35 USC §102 

8. The following is a quotation of the appropriate paragraphs of 35 U.S. C. 102 that form the 
basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(b) the invention was patented or described in a printed publication in this or a foreign country or in public use or on 
sale in this country, more than one year prior to the date of application for patent in the United States. 

Claims 1-12 are rejected under 35 U.S.C. 102(b) as being anticipated by Medvinsky et al. (US 
Pub No. 2001/0047484 Al), hereinafter Medvinsky. 

As per claim 1, Medvinsky discloses: 

- generating by said user equipment (EQUIP) a credential (C(P-U2; XID21) based 
upon a user password (P-U2) being associated to said user (U2) and a session parameter 
(XID21) being determined by said user equipment (EQUIP) for said session which is actual 
being established (Medvinsky, Abstract, "A method for an uninitialized client to obtain 
credentials from a server which are then used to provide authenticated exchange for network 
configuration parameter assignment. The obtained credentials can be applied to an authentication 
option when a dynamic host configuration protocol (DHCP) is being used for address 
assignment"), where "client" is the user, inherently user's equipment, as claimed; 

- comprising in a session message (DISCOVER(USER2; Xff)21; C(P-U2; XID21))) 
of said protocol (DHCP) a user identification (USER2) that uniquely identifies said user 
(U2), said session parameter (XID21) and said generated credential (C(P-U2; XID21)) 
(Medvinsky, paragraph [ 0011], "A "Key Distribution Center" ("KDC") is a network service that 
supplies tickets and temporary session keys; or an instance of that service or the host on which it 
runs. The KDC services both initial ticket and ticket-granting ticket (TGT) requests. The initial 
ticket portion is sometimes referred to as "authentication server" (or "authentication service"). 
The ticket-granting ticket portion is sometimes referred to as the ticket-granting server (or "ticket 
granting service")"); 

-forwarding said session message (DISCOVER (USER2; XID21; C(P-U2; XID21))) 
by said user equipment (EQUIP) to said authentication device (AUTH) (Medvinsky, 
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paragraph [0012], "DHCP" defines the protocol exchanges for a client to obtain its IP address 
and network configuration information from a DHCP Server. Kerberos V5 defines the protocol 
and message exchanges to mutually authenticate two parties"); 

- upon reception by said authentication device (AUTH) of said session message 
(DISCOVER(USER2; XID21; C(P-U2; XID21))) verifying said received credential (C(P- 
U2; XID21)) with a generated verification credential (VC(P-U2; XID21)) based upon said 
received session parameter (XID21) and said user password (P-U2) being associated to said 
received user identification (USER2) and thereby providing said authentication for said 
user (U2) (Medvinsky, paragraph [0096], " AP REQ contains the Kerberos ticket for the DHCP 
server and also contains information needed by the DHCP server to authenticate the client. After 
verifying the AP REQ and decrypting the Kerberos ticket, the DHCP server is able to extract a 
session key which it now shares with the DHCP client"). 

As per claim 2, claim 1 is incorporated and Medvinsky discloses: 

It is inherent that user's account/profile must be in the authentication server in order t o 
provide authentication based on rules. 

As per claim 3 claim 1 is incorporated and Medvinsky discloses: 

-The method to provide an authentication for a user (U2) according to claim 1, 
characterized in that said protocol (DHCP) is a Dynamic Host Configuration Protocol 

(Medvinsky, Abstract, A method for an uninitialized client to obtain credentials from a server 
which are then used to provide authenticated exchange for network configuration parameter 
assignment. The obtained credentials can be applied to an authentication option when a dynamic 
host configuration protocol DHCP is being used for address assignment"). 

As per claim 4, claim 1 is incorporated and Medvinsky discloses: 

- (original): The method to provide an authentication for a user (U2) according to 
claim 1, characterized in that said session message (DISCOVER(USER2; XID21; C(P-U2; 
XID21))) is a Discover message of a Dynamic Host Configuration Protocol (Medvinsky, 
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paragraph [0010], "A "DHCP" client" is an internet host using DHCP to obtain configuration 
parameters such as a network address. A "DHCP server" is an internet host that returns 
configuration parameters to DHCP clients. A "ticket" is a Kerberos term for a record that helps a 
client authenticate itself to a server. A ticket contains the client's identity; a session key, a 
timestamp, and other information, all sealed using the server's secret key. A ticket serves to 
authenticate a client when presented along with a fresh authenticator"), where "session key", 
"timestamp" are the parameter in the session (message)"). 

As per claim 5, claim 4 is incorporated and Medvinsky discloses: 

- The method to provide an authentication for a user (U2) according to 
claim 4, characterized in that said user identification (USER2), said session parameter 
(XID21) and said generated credential (C(P-U2; X1D21)) being included as a predefined 
Option in an Option field of said Discover message (Medvinsky, paragraph [0015], "Kerberos 
is a secure key management mechanism that is based on a trusted 3.sup.rd party, the KDC. In 
Kerberos a client performs mutual authentication with the KDC and in the process obtains 
credentials (e.g., a Kerberos ticket) that it needs for authentication to an application server (e.g., 
the DHCP server). The client can then use the Kerberos ticket to perform mutual authentication 
with the DHCP server and to establish a shared session key that would be used for subsequent 
message authentication"). 

As per claim 6, claim 1 is incorporated and Medvinsky discloses: 

- The method to provide an authentication for a user (U2) according to claim 1 
characterized in that said session parameter (XID21) is a session identifier that uniquely 
identifies said session that is actual being established (Medvinsky, paragraph [0010], "A ticket 
contains the client's identity, a session key, a timestamp, and other information, all sealed using 
the server's secret key. A ticket serves to authenticate a client when presented along with a fresh 
authenticator"), where "session key" is the unique identifier of a session, as claimed. 

As per claim 7, Medvinsky discloses: 
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- a first generator (GEN1) to generate a credential (C(P-U2; XID21) based upon a 
user password (P-U2) being associated to said user (U2) and a session parameter (XID21) 
being determined by said user equipment (EQUIP) for said session which is actual being 
established (Medvinsky, paragraph [0010], "A ticket contains the client's identity, a session key, 
a timestamp, and other information, all sealed using the server's secret key. A ticket serves to 
authenticate a client when presented along with a fresh authenticator"), where "ticket" is the 
credential, which is generated to function uniqueness of authenticity, as claimed. 

- a second generator (GEN2) to comprise in a session message (DISCOVER(USER2; 
XID21; C(P-U2; XID21))) of said protocol (DHCP) a user identification (USER2) uniquely 
identifying said user (U2), said session parameter (XID21) and said generated credential 
(C(P- U2; XID21)) and to forward said session message (DISCOVER(USER2; XID21; C(P- 
U2; XID21))) to said authentication device (AUTH) in order to enable thereby said 
authentication device (AUTH), upon reception of said session message 
(DISCOVER(USER2; XID21; C(P-U2; XID21))) to verify said received credential (C(P- 
U2; XID21)) with a generated verification credential (VC(P-U2; XID21)) based upon said 
received session parameter (XID21) and said user password (P-U2) that is associated to 
said received user identification (USER2) and to provide thereby said authentication for 
said user (U2) (Medvinsky, paragraph [0020], "An authentication and parameter exchange 
sequence can be initiated by a DCHP-client broadcast or other appropriate Kerberos message. 
The proxy, which can be invisible to the client ... authentication and parameter assignment 
exchanges (e.g. including an IP address assignment) can be conducted in a largely conventional 
manner"), where "broadcasting session message" with session parameter to authenticate, as 
claimed. 

As per claim 8, Medvinsky discloses: 

- a third generator (GEN3) to generate a verification credential (VC(P-U2; XID21)) 
based upon a received session parameter (XID21) and based upon a user password (P-U2) 
that is associated to a received user identification (USER2), and to provide said verification 
credential (VC(P-U2; XID21)) to a verifier (VER) (Medvinsky, paragraph [0091], "The client, 
upon receiving a broadcast response having a link layer destination address as its hardware 
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address and a network layer address as the broadcast address, must verify that the hardware 
address in the ticket corresponds to its link layer address. Upon receiving a TGSREP (or an 
AS REP with the application server ticket) from the proxy, the client will have enough 
information to securely communicate with the application server (the DHCP-server in this case), 
as specified in the following section"); 

- said verifier (VER) coupled to said third generator (GEN3) to verify said 
verification credential (VC(P-U2; XID21)) against a received credential (C(P-U2; XID21)) 
and to provide thereby said authentication for said user (U2) (Medvinsky, paragraph 
[00502], "This can be initiated as shown by block 920 in which an authenticated first message 
from the client to the server is sent as part of the authenticated address assignment protocol. 
Thus, the server can utilize the credentials to authenticate this first message received from the 
client, as illustrated by block 924"); 

- said received user identification (USER2), said received session parameter (XID21) 
and said received credential (C(P-U2; XID21)) being comprised by said user equipment 
(EQUIP) in a session message (DISCOVER(USER2; XID21; C(P-U2; XID21))) of said 
protocol (DHCP) (Medvinsky, paragraph [0045], "As with system 100 of FIG. 1, the substantial 
decoupling present in system 200 (FIG. 2) enables the authentication phase to be conducted in a 
manner largely consistent with that of a conventional Kerberos key management exchange. That 
is, a client gets a ticket granting ticket ("TGT") by contacting an authentication server within a 
KDC using As Request and Reply messages (see FIG. 5). The client then contacts a Ticket 
Granting Server in a KDC to get a server ticket using TGS REQ and TGS REP messages 
(which ticket permits initiation of the parameter exchange phase). It is also possible for a client 
to obtain a DHCP server ticket directly with the AS Request/Reply exchange, and without the 
use of the TGT"); 

- said credential (C(P-U2; XID21) being generated by said user equipment (EQUIP) 
based upon said user password (P-U2) that is uniquely associated to said user (U2) and said 
session parameter (XID21) that is determined by said user equipment (EQUIP) for said session 
which is actual being established (Medvinsky, paragraph [0103], [0104], "The above examples 
could also be modified such that DHCPclients would not require any additional configuration 
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information other than a password or a key (and a public key certificate if PKINIT is useed. In 
the above examples, the Kerberos session key is used directly as an HMAC key to authenticate 
DHCP message. Standard security practice, however, is to use different keys for different 
purposes. Thus, the Kerberos session key is used to encrypt a part of an AP REQ message"); 

- said session message (DISCOVER(USER2; XID21; C(P-U2; XID21))) being 
forwarded by said user equipment (EQUIP) to said authentication device (AUTH) 
(Medvinsky, paragraph [0079], "The client sends TGS Request for a principal name Mhcpsrvf 
with the realm found in the TGT to the proxy"). 

As per claim 9, claim 8 is incorporated and Medvinsky discloses: 

- The authentication device (AUTH) according to claim 8, characterized 
in that said authentication device is at least partly included in a network access provider 
(NAP) (Medvinsky, paragraph [0043], "Customized hardware might also be utilized and/or 
particular elements might be implemented in hardware, software (including so-called "portable 
software," such as applets) or both. Further, while connection to other computing devices such as 
network input/output devices (not shown) may be employed, it is to be understood that wired, 
wireless, modem and/or other connection or connections to other computing devices might also 
be utilized"). 

As per claim 10, claim 6 is incorporated and Medvinsky discloses: 

- Telecommunication network to provide an authentication for a user (U2), 
characterized in that said telecommunication network comprises a user equipment 
(EQUIP) according to claim (Medvinsky, Abstract, "A method for an uninitialized client to 
obtain credentials from a server which are then used to provide authenticated exchange for 
network configuration parameter assignment. The obtained credentials can be applied to an 
authentication option when a dynamic host configuration protocol DHCP is being used for 
address assignment"), where computer network is capable of carry data, video and voice, as 
claimed. 

As per claim 9, claim 8 is incorporated and Medvinsky discloses: 
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- An authentication device (AUTH) according to claim 7(Medvinsky, paragraph 
[0043], "Operating system utilization will also vary depending on the particular host devices 
and/or process types (e.g. computer, appliance, portable device, etc"). 

As per claim 9, claim 8 is incorporated and Medvinsky discloses: 

- An authentication device (AUTH) according to claim 8 (Medvinsky, paragraph 
[0043], "Operating system utilization will also vary depending on the particular host devices 
and/or process types (e.g. computer, appliance, portable device, etc"). 

Conclusion 

9 The prior art made of record and not relied upon is considered pertinent to applicant's 
disclosure (see form "PTO-892 Notice of Reference Cited"). 

Any inquiry concerning this communication or earlier communications from the examiner 
should be directed to Monjour Rahim whose telephone number is (571)270-3890. The examiner 
can normally be reached on 5:30 AM -3:30 PM (Mo-Th). 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Chameli Das can be reached on (571)272-3696. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (in USA or CANADA) or 571-272-1000. 

/Monjour Rahim/ 
Patent Examiner 
Art Unit: 2134 
Date: 06/18/2008 
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